ci: support for jobName flag and v3 messages#4288
Merged
sombraSoft merged 1 commit intoJun 17, 2026
Merged
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request introduces a new --jobName command-line argument to uploadMetadata.py, enabling the emission of schema v3 payloads to Pub/Sub when a job name is provided. The review feedback suggests sanitizing the --jobName argument by stripping leading and trailing whitespaces. This ensures that empty or whitespace-only values do not incorrectly trigger schema v3, both when building the payload and when publishing the pipeline report.
Adds a --jobName argument to flow/util/uploadMetadata.py so the QoR metadata published to Pub/Sub can carry the canonical Jenkins pipeline name. When supplied (and non-blank after stripping whitespace), the message is emitted as schema v3 (the v2 structure plus a top-level job_name); otherwise the script behaves as before and emits v2. This lets the palantir backend resolve the pipeline directly from job_name instead of classifying the raw BUILD_TAG with a hardcoded pattern table, so new pipelines appear on the dashboard without a backend code change. The >8 MB per-design fallback path is unchanged - it still emits v1 messages, which the backend continues to resolve via BUILD_TAG. Signed-off-by: Miguel Pedro <miguel.pedro@precisioninno.com>
openroad-ci
force-pushed
the
ci-jobname-support
branch
from
c4ac310 to
4cb875c
Compare
sombraSoft
approved these changes
Jun 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a
--jobNameargument toflow/util/uploadMetadata.pyso the QoR metadata published to Pub/Sub can carry the canonical Jenkins pipeline name. When the argument is supplied, the message is emitted as schema v3 (the existing v2 structure plus a top-leveljob_name); when it is omitted, the script behaves exactly as before and emits v2.This lets the palantir backend resolve the pipeline directly from job_name instead of classifying the raw BUILD_TAG with a hardcoded pattern table, so new pipelines appear on the dashboard without a backend code change.
What changed
--jobNameargument (defaults to None).build_pipeline_payloadsetspayload_schema_versionto 3 and adds job_name when --jobName is set; otherwise stays on 2. The backend requires a non-blankjob_namefor v3, so a blank value safely falls back to v2 and the legacy classifier.publish_pipeline_reportsets the Pub/Sub `payload_schema_version`` message attribute to match the body (3 or 2).